Generally, this invention pertains to the protection of intellectual property (IP) that is available to a user for evaluation purposes. More specifically, the invention pertains to secure simulation models of IP cores that allow the user to evaluate the IP cores in electronic design automation (EDA) systems, but prevent the user from implementing the IP cores in a useful hardware device.
EDA systems have become integral to the development of electronic designs for implementation in devices such as programmable logic devices (PLDs) and field programmable gate arrays (FPGAs). An EDA system provides various tools that receive a user's high-level representation of an electronic design and convert it to a form suitable for programming the programmable device. EDA systems may include tools for design entry, compilation, synthesis, mapping, verification, generating a programming file, etc. In addition, EDA systems typically include a simulation tool for confirming that the electronic design is likely to operate as intended.
During the process of creating an electronic design, a user may employ one or more reusable IP cores. These are predefined and preverified functional blocks for performing well-defined tasks that may be incorporated into a user's electronic design. In some cases, they may define an entire electronic design itself. Frequently, they are configurable by a user who can specify one or more parameters appropriate for the desired application. They are designed to work well with existing EDA tools so that users can easily input them into their electronic designs.
IP cores may be viewed broadly to include “megacores,” “megafunctions” and other predefined logic blocks for implementation in programmable devices. Megacores define large complex functional blocks such as microprocessors and sophisticated communications blocks such as a block for terminating a trunk protocol on a fiber optic link. Megafunctions define smaller functional blocks such as a DSP filter, multiplier, or FIFO memory. Collections or libraries of simple parameterized megafunctions are available. One example is the library of parameterized modules (“LPM”) developed tinder the guidance of the EDIF association.
A user must have authorization (e.g., a license) to implement an IP core in the target hardware devices. The authorization typically comes with a cost that is dependant on the value of the IP core being implemented as well as the type of relationship that exists between the user and the IP core vendor.
In the modern EDA environment, IP core vendors usually allow users to evaluate the IP cores before deciding whether to implement them into a final design. Thus, the vendors must provide their cores in a form that allows both evaluation and compilation to a final hardware programming file. Evaluation requires simulation on one of the many available EDA simulation tools. Therefore an IP core vendor typically provides a customer with two forms of a core: (1) a programming version in the form of source code and/or synthesized netlist for compiling the IP core to a programming file using a particular EDA tool (e.g., Quartus available from Altera Corporation of San Jose, Calif.); and (2) a simulation version that can be executed on a specific third party simulator to evaluate the IP core.
Vendors must be concerned with the possibility of unauthorized use of their IP cores. In one example, the programming version of the IP core is converted to a programming file and used to program hardware devices without a license from the IP core vendor. In another example, a user ports an electronic design containing the IP core to a competitor's hardware platform.
In order to address the issue of unauthorized usage, both the programming version and the simulation version must be protected. One approach to protecting the programming version involves encrypting the IP core's source code and/or synthesized netlist. Another approach is to check for a licensing file before generating a programming file for the target hardware device. These approaches do a good job of protecting the programming version of an IP core from unauthorized use. However, they are not practical for protecting the simulation version of the core. While the programming version can be designed for use with a single EDA platform (e.g., Altera's Quartus), the simulation version typically must work with many different simulation tools. For example, Quartus and other EDA platforms work with multiple different simulation tools, each of which may be provided by a different vendor. Examples of simulation tools include ModelSim by Mentor Graphics Corp. (Wilsonville, Oreg.); Verilog-XL and NC-Verilog simulators by Cadence Design Systems, Inc. (San Jose, Calif.); and VCS simulator by Synopsys, Inc. (Mountain View, Calif.).
Because the simulation version of an IP core must work with a heterogeneous group of simulation tools, security features must work with each of many different tools. One could provide a simple source code version of the IP core for simulation (e.g., Verilog), which could be compiled to the appropriate machine code for any of a number of different simulators. But this approach would provide little if any security. A user could modify the source slightly to allow compilation to a programming file that would circumvent the licensing requirements of the IP vendor.
To provide much greater security, a vendor could provide precompiled versions of the simulation model for each of the available simulation tools on the market. Unfortunately, this would not be practical. The vendor would need to maintain updated versions of the IP for each of a wide range of third party simulation tools. And because many of these tools can run on various computer platforms, a separate compiled version of the IP would be required for each combination of simulator and hardware platform. The problem is exacerbated by the myriad of configuration possibilities for each IP core. For example, a particular core might have 20 or more configurations (depending on user settings). Therefore, the IP vendor might have to provide a separate compiled version of the core for each of these 20 or more configurations (on each of the simulator-hardware combination). Obviously, it would be economically impossible for a vendor to maintain a full range of simulation models.
Another approach to providing the simulation models gives the actual source code of the simulation model to trusted users only (e.g., employees of large companies known to maintain close control over the IP). Unfortunately, this limits the market available to IP vendors. In yet another approach, the IP core vendor provides an equivalent behavioral model of the simulation model. A behavioral model cannot be compiled to produce a working program file for implementing the design on hardware devices. Unfortunately, this approach has its drawbacks in that it usually will not produce a model that is cycle and bit accurate.
There are some EDA system tools such as “VIP” (Visual IP available from Summit Design (Burlington, Mass.)) that attempt to address the problem of making secure simulation versions of IP cores. VIP can generate a secure simulator-independent simulation model, but requires use of various special purpose VIP proprietary tools (e.g., translation programs and adaptors), which must be purchased by the user. Obviously, an IP vendor would prefer not to force potential customers to purchase third-party tools that protect the vendor. Further, VIP generated simulation models are generally large, slow, and require PLI/FLI setup that is difficult to use and is time consuming.
What is needed therefore is an improved approach to providing IP cores that allow simulation in many different third-party simulation tools and at the same time affords security for the IP core vendor.